Smartphones have surpassed desktop machines in sales in 2011 to become the most prevalent computing platforms. To enrich the user experience, modern day smartphones come with a host of hardware I/O components embedded in them. The list of components broadly fall into two categories: traditional components such as CPU, WiFi NIC, 3G radio, memory, screen and storage that are also found in desktop and laptop machines, and exotic components such as GPS, camera and various sensors. And they differ from their desktop/laptop counterparts in that power consumed by individual I/O components is often comparable to, or higher than, the power consumed by the CPU.
This, along with the fact that smartphones have limited battery life, dictates that energy has become the most critical resource of smartphones. Preserving this crucial resource has driven smart-phone OSes to resort to a paradigm shift in component power management. On desktop machines, where the CPU accounts for a majority of the energy consumption, the default energy management policy is that the CPU stays on (or runs at a high frequency) unless an extended period of low load has been observed. The policy is consistent with the historical notion that energy management is a second class citizen since machines are plugged into a power source. Smart phones, in sharp contrast, make power management policy a first class citizen. In fact, the power management policy on smartphones has gone to the other extreme: the default power management policy is that every component, including the CPU, stays off or in an idle state, unless the app explicitly instructs the OS to keep it on.
In particular, all smartphone OSes, e.g., Android, IOS, and Windows Mobile, employ an aggressive sleeping policy which put the components of the phone to sleep, i.e., puts them into a suspended state immediately following a brief period of user inactivity. In the suspended state, the smartphone as a whole draws near zero power, since nearly all the components, including CPU, are put to sleep. Such a sleeping policy is largely responsible for prolonged smartphone standby times—smartphones can last dozens of hours when suspended.
The aggressive sleeping policy, however, severely impacts smartphone apps, since an app may be performing critical tasks by intermittently interacting with the external world using various sensors. For example, an app syncing with a remote server over the network may appear to perform no activity when waiting for the server to send its reply, and the system may be put to sleep by the aggressive sleeping policy, leaving the remote server with a view of lost connectivity.
To avoid such disruptions due to the aggressive sleeping policy, smartphone OSes provide a set of mechanisms for app developers to explicitly notify the OS of their intention to continue using each component. In particular, the OS exports explicit power management handles and APIs, typically in the form of power wakelocks and acquire and release APIs, for use by the app developer to specify when a particular component needs to stay on, or awake, until it is explicitly released from duty.
Explicit management of smartphone components by app developers has presented to the app developer a profound paradigm shift in smartphone programming that we call power-encumbered programming. This new programming paradigm places a significant burden on developers to explicitly manipulate the power control APIs (e.g., the below section relating to no sleep code path details one such example of the burden placed on developer due to power encumbrance). This manipulation is required to ensure the correct op-ratio of the apps. Consequently, power-encumbered programming unavoidably gives rise to a new class of software energy bugs on smartphones, called no-sleep bugs. No-sleep bugs are defined as energy bugs resulting from mishandling power control APIs in an app or framework, resulting in the smartphone components staying on for an unnecessarily long period of time. No-sleep bugs form one important category of the family of smartphone energy bugs which are defined in as errors in the smartphone system (an app or the framework, the OS, or the hardware) that cause an unexpectedly high energy consumption by the system as a whole.
Discussions of energy bugs on numerous Internet forums have narrowed the causes to mishandling of power control APIs by apps and the framework on smartphones OSes, including Android, DOS, and Windows Mobile. Our previously published recent survey (“A. Pathak, Y. C. Hu, and M. Zhang, “Bootstrapping energy debugging for smartphones: A first look at energy bugs in mobile devices,” in Proc. of Hotnets, 2011) found that 70% of all energy problems in apps and frameworks reported by mobile users were due to no-sleep energy bugs. These and other types of energy bugs have caused a great deal of user frustration. Despite their severity, i.e., high battery drain, to the best of our knowledge there has been no study of any kind of smart phone energy bugs, much less no-sleep energy bugs. Research works exists in traditional software bugs relating to concurrency bugs in concurrent programs (S. Lu, S. Park, E. Seo, and Y. Zhou, “Learning from mistakes—a comprehensive study on real world concurrency bug characteristics,” in ASPLOS, 2008).